SYSTEM AND METHOD FOR PROVIDING WARRANTIES IN ELECTRONIC 
COMMERCE 

This application is a continuation of United States patent application serial No. 

5 09/928,998, filed August 14, 2001, entitled System and Method for Providing Warranties in 
Electronic Commerce, which claimed priority fi-om U.S. provisional patent application 
serial No. 60/224,994, filed August 14, 2000, entitled Signing Interface Compliance 
Requirements, Smart Card Compliance Requirements, Warranty Service Functional 
Requirements, and Additional Disclosure; and U.S. provisional patent application serial No. 

10 60/259,796, filed January 4, 2001, entitled Warranty Manager Application Programming 
Interface, Warranty Messaging Specification, and Warranty Manager Functional 
Requirements, all three of which are hereby incorporated by reference. 

COPYRIGHT NOTICE 

15 A portion of the disclosure of this patent document contains material which is 

subject to copyright protection. The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent disclosure, as it appears in the 
Patent and Trademark Office patent file or records, but otherwise reserves all copyright 
rights whatsoever. 

20 

BACKGROUND OF THE INVENTION 

The world of electronic commerce has created new challenges to establishing 
relationships between contracting parties. One of those challenges springs fi*om the fact that 
the parties to the transaction cannot see or hear each other, and cannot otherwise easily 

25 confirm each other's identity and authority to act. 

One remedy for this problem is to provide each contracting party with a private key 
for signing transmitted messages. The signing party makes available an associated public 
key that decrypts messages signed with the party's private key, and thus enables a receiving 
party to confirm the identity of the sender. 

30 But the sender's public key may not be known a priori to the recipient. In that 

event, the sender may transmit with its signed message a digital certificate issued by a 
certification authority. The certificate is itself a signed electronic document (signed with the 
private key of the certification authority) certifying that a particular public key is the public 
key of the sender. 
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In some cases, the recipient may be unfamiliar with the pubhc key of the 
certification authority or may not know whether the certificate is still valid. In that event, 
the recipient may wish to check the validity of the certificate with an entity that it trusts. In 
addition, the recipient may wish to obtain a financial guarantee to protect itself against 
5 damage that it may suffer from reliance on an invalid certificate. 

SUMMARY OF THE INVENTION 
A system and method are disclosed for providing warranties that financially 
guarantee one or more facts associated with a an electronic transaction. In a preferred 
10 embodiment, the warranties are provided within the context of a four-comer trust model. 
The four-comer model comprises a buyer, also referred to as the subscribing customer, and 
a seller, also referred to as the relying customer, who engage in an on-line transaction. 

In a preferred embodiment, the buyer is a customer of a first financial institution, 
referred to as an issuing participant. The issuing participant acts as a certification authority 
15 for the buyer and issues the buyer a hardware token including a private key and a digital 
certificate signed by the issuing participant. 

In a preferred embodiment, the seller is a customer of a second financial institution, 
referred to as the relying participant. The relying participant acts as a certification authority 
for the seller and issues the seller a hardware token including a private key and a digital 
20 certificate signed by the relying participant. The system also includes a root entity that 
maintains a root certification authority that issues digital certificates to the issuing and 
relying participants. 

In a preferred embodiment, a warranty issued in the present system comprises a 
contract between a first party and a second party in which the first party: (1) warrants one or 
25 more warranted facts (2) for damages up to a warranted amount (3) if claimed by a relying 
customer within a claim period. The warranty is preferably issued by a participant in 
response to a request received from a customer that specifies a desired warranted amount 
and claim period. The participant and root entity evaluate the request in light of a plurality 
of factors and determine whether or not the warranty should be issued. In a preferred 
30 embodiment, the warranty comprises a contract between the buyer and its issuing 
participant. The seller is preferably a third-party beneficiary of this contract. 

In a preferred embodiment, in order to manage the liability risks associated with 
issuing warranties, the root entity imposes a series of limits, called participant warranty 
caps, on the warranty volume that each issuing participant may have outstanding. These 
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caps are intended to limit the aggregate level of operating risk exposure for individual 

participants and to limit the overall risk in the system. 

If a seller suffers damage as a result of its reliance on a v^arranted fact, the seller may 

file a claim for compensation against the issuing participant. If the issuing participant 
5 determines to pay the claim, it transfers sufficient funds to the relying participant for the 

benefit of the seller. If the issuing participant determines to dispute the claim, the issuing 

participant and seller proceed to dispute resolution. 

In a preferred embodiment, the root entity imposes collateral requirements on the 

issuing participant that may be used to pay claims for damages filed by sellers if the issuing 
10 participant is unable or unwilling to satisfy a warranty claim. The collateral is preferably 

held by a third-party collateral agent that is contractually obligated to pay warranty claims 

fi-om the issuing participant's collateral account if ordered to do so imder system operating 

rules. 

The features and advantages described in the specification are not all inclusive, and 
15 many additional features and advantages will be apparent to one of ordinary skill in the art 
in view of the drawings, specification, and claims hereof. 

BRIEF DESCRIPTION OF THE DRAWINGS 
The above summary of the invention will be better understood when taken in 
20 conjunction with the following detailed description and accompanying drawings, in which: 
FIG. 1 is a block diagram of a preferred embodiment of a four-comer model suitable 
for use in the present system; 

FIG. 2 is a block diagram of a preferred embodiment showing components provided 
at entities in the four-comer model; 
25 FIG. 3 illustrates a preferred embodiment of a warranty-issuance process flow; 

FIG. 4 illustrates a preferred embodiment of certain messages used in the preferred 
embodiment of FIG. 3; 

FIG. 5 illustrates a preferred embodiment of certain messages used in the preferred 

embodiment of FIG. 3; 

30 FIG. 6 illustrates a preferred embodiment of certain messages used in the preferred 

embodiment of FIG. 3; 

FIG. 7 illustrates a preferred embodiment of a warranty-claim process flow; 

FIG. 8 illustrates a preferred embodiment of certain messages used in the preferred 
embodiment of FIG. 7; 
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FIG. 9 illustrates a preferred embodiment of a process for collateral updating and 
monitoring; 

.FIG. 10 illustrates a preferred embodiment for implementing a warranty manager; 
FIG. 1 1 illustrates an altemative preferred embodiment for implementing a warranty 
5 manager; 

FIG. 12 illustrates a preferred embodiment of data elements used to construct 
warranty messages; 

FIG. 13 illustrates a preferred embodiment of data descriptions and restrictions for 
the data elements in FIG. 12; 
10 FIG. 14 illustrates a preferred embodiment of data elements used to construct 

warranty claims messages; and 

FIG. 15 illustrates a preferred embodiment of data elements, and corresponding 
descriptions and restrictions, used to construct validation reporting messages. 

15 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The present disclosure relates to a system and method for providing warranties that 
financially guarantee one or more facts associated with an electronic transaction. In a 
preferred embodiment, warranties are provided within the context of a four-comer tmst 
model. A preferred embodiment of the four-comer model is shown in FIG. 1. 

20 As shown in FIG. 1 , the four-comer model preferably comprises a first institution 

102 and a second institution 104. First institution 102 is referred to as the "issuing 
participant" because it is a participant in the present system and issues to its customers 
tokens that include a private key and a digital certificate signed by the issuing participant, as 
described below. Second institution 104 is referred to as the "relying participant" because it 

25 is a participant in the present system and its customers rely on representations made by 
issuing participant 102 and issuing participant 102's customers, as described below. 
Participants 102, 104 may preferably be banks or other financial institutions. 

Also shown in FIG. 1 are a first customer 106 and a second customer 108. First 
customer 106 and second customer 108 are preferably customers of issuing participant 102 

30 and relying participant 104, respectively. First customer 106 is referred to as the 

"subscribing customer" because this customer subscribes to services provided by issuing 
participant 102. First customer 106 is also referred to as the "buyer" because it typically 
fills that role in transactions with second customer 108, as described below. 

Second customer 108 is referred to as the "relying customer" because it relies on 

35 representations made by both issuing participant 102 and subscribing customer 106. Second 
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customer 108 is also referred to as the "seller" because it typically fills that role in 
transactions with subscribing customer 106, as described below. It should be recognized, 
however, that although the description below speaks primarily in terms of a buyer 106 and a 
seller 108, first customer 106 and second customer 108 may instead have different roles in a 

5 given transaction. For example, first customer 106 may be a borrower repaying a loan to 
second customer 108. 

Also shown in FIG, 1 is a root entity 1 10. Root entity 1 10 is preferably an 
organization that establishes and enforces a common set of operating mles for faciUtating 
electronic commerce and electronic communications. Root entity 110 may be owned jointly 

10 by a plurality of banks and/or other financial institutions that have agreed to adhere to these 
operating rules. One exemplary embodiment of such a root entity is described in copending 
U.S. application serial No. 09/502,450, filed February 11, 2000, entitled System and 
Method for Providing Certification Related and Other Services and in copending U.S. 
application serial No, 09/657,623, filed September 8, 2000, entitled System and Method for 

1 5 Providing Certificate-Related and Other Services, which are hereby incorporated by 
reference, 

FIG, 2 illustrates components provided at each entity in a preferred embodiment of 
the present system. As shown in FIG. 2, participants 102, 104, and root entity 1 10 are each 
preferably provided with a transaction coordinator 202 that serves as a gateway for 

20 transmitting and receiving all inter-entity messages related to services provided by the 
present system. Transaction coordinators 202 provide a single interface to issuing 
participant 102's and relying participant 104's on-line services and implement safeguards 
necessary to ensure secure electronic communications between transaction coordinators 202 
and other entities in the four-comer model, as described in copending U.S. patent 

25 application serial No. 09/657,605, filed on September 8, 2000, entitled System and Method 
for Providing Certificate Validation and Other Services, which is hereby incorporated by 
reference. Each transaction coordinator 202 is preferably provided with an associated 
hardware security module (HSM) 21 8 for signing and verifying messages. Participants 102, 
104, and root entity 1 10 are each fiuther preferably provided with an Online Certificate 

30 Status Protocol (OCSP) responder 204 and associated HSM 206 for signing and verifying 
signatures on messages. 

Participants 102, 104, and root entity 1 10 are each further preferably provided with a 
warranty manager 230. Warranty manager 230 is adapted to receive and transmit messages 
relating to warranty services and evaluate warranty requests, as described in more detail 

35 below. 
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As further shown in FIG. 2, relying customer 108 is preferably provided with a Web 
server 220 adapted to receive and transmit information via the Internet and a bank interface 
222 for accessing system services. An exempleiry bank interface is described in copending 
U.S. application serial No. 09/657,604, filed on September 8, 2000, entitled System and 

5 Method for Facilitating Access by Sellers to Certificate-Related and Other Services, which 
is hereby incorporated by reference. Relying customer 108 is preferably further provided 
with an HSM 250 for signing and verifying signatures on messages. 

As further shown in FIG. 2, subscribing customer 106 is preferably provided with a 
Web browser 224 adapted to receive and transmit information via the Intemet. Subscribing 

10 customer 106 is also preferably provided with a smartcard subsystem 226 adapted to sign 
electronic messages. In a preferred embodiment, smartcard subsystem 226 may include a 
smartcard reader, a smartcard driver, a smartcard token, and other software, as described in 
U.S. provisional application serial No. 60/224,994, filed August 14, 2000, entitled Signing 
Interface Requirements, Smart Card Compliance Requirements, Warranty Service 

15 Functional Requirements, and Additional Disclosure and U.S. application serial No. 

filed August 14, 2001, entitled System and Method for Secure Smartcard 

Issuance, which are hereby incorporated by reference. In a preferred embodiment, the 
smartcard token is issued to subscribing customer 106 by its issuing participant 102. 

Subscribing customer 106 is also preferably provided with a signing interface 225. 

20 Signing interface 225 is adapted to invoke smartcard 226 to execute a digital signature, as 
described in U.S. provisional application serial No. 60/224,994, filed August 14, 2000, 
entitled Signing Interface Requirements, Smart Card Compliance Requirements, Warranty 
Service Functional Requirements, and Additional Disclosure and U.S. application serial No. 
, filed August 14, 2001, entitled System and Method for Facilitating Signing by 

25 Buyers in Electronic Commerce, which are hereby incorporated by reference. 

In a preferred embodiment, each system entity is further preferably provided with 
two digital certificates (and corresponding private keys) to facilitate authentication: an 
identity certificate and a utility certificate. 

The identity private key is used to produce digital signatures that are required by 

30 root entity 1 1 0 as evidence of an entity's contractual commitment to the contents of an 
electronic transaction, such as a purchase order. 

The utility private key is used to provide additional transactional security. Typically, 
utility certificates are used to support secure socket layers (SSL), to sign secure 
multipurpose intemet mail extension (S/MIME) messages, and for other utility applications. 

35 
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Any reference in this document to the term "certificate" refers to an identity certificate 
unless otherwise stated. 

In a preferred ernbodiment, root entity 1 10, in its capacity as a certification authority, 
uses a root private key to create the digital certificates of each system participant (e.g., 
5 issuing participant 102 and relying participant 104). In addition, it uses the root private key 
to create digital certificates for each system component maintained by root entity 110 that 
has digital signing capability, including OCSP responder 204r and transaction coordinator 
202r. 

In addition, each system participant (e.g., issuing participant 102 and relying 

10 participant 104), in its capacity as a certification authority, uses the private key associated 
with its certificate from root entity 1 10 to create the digital certificates of its customers (e.g., 
subscribing customer 106 and relying customer 108). In addition, it uses this private key to 
create digital certificates for each system component that it maintains that has digital 
signing capability, including its OCSP responder 204 and transaction coordinator 202. In an 

15 altemative embodiment, the digital certificates for system components with digital signing 
capability that are maintained by a participant may be issued by root entity 110. 

It should also be recognized that each customer 106, 108, may be a business entity, 
such as a corporation, that employs many individuals. In such cases, customers 106, 108 
preferably authorize some or all of these individual employees to transact and utilize system 

20 services on their behalf Issuing participant 102 preferably issues a separate smartcard 
token having a distinct private key and associated digital certificate to each authorized 
employee of subscribing customer 106. Similarly, relying participant 104 (in its capacity as 
"issuing participant" to relying customer 108) preferably issues a separate smartcard token 
having a distinct private key and associated digital certificate to each authorized employee 

25 of relying customer 108. The digital certificates preferably include the individual 

employee's name and identify the customer for whom he or she works. In an altemative 
embodiment, the private key may instead be included in a software token provided to the 
individual. 

Although the preferred embodiment described above employs transaction 
30 coordinators at each participant 102, 104 and at root entity 1 10, it should be noted that, in an 
altemative embodiment, the system may be designed without some or all of these 
transaction coordinators. In this altemative embodiment, messages created, signed, or 
transmitted by, to, or via a transaction coordinator in the following description, may instead 
be created, signed, or transmitted by, to, or via a substitute system component adapted to 
35 comprise appropriate hardware and/or software to provide the desired fimctionality. 
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Warranty Products 

Before describing in detail preferred embodiments for requesting and issuing 
warranties, an overview of the preferred warranty products provided by the present system 
is presented. In a preferred embodiment, a warranty issued in the present system comprises 

5 a contract between a first party and a second party in which the first party: (1) warrants one 
or more warranted facts (2) for damages up to a warranted amount (3) if claimed by a 
reljdng customer within a claim period. 

In a preferred embodiment, the warranted facts include: (a) that a subscribing 
customer 106 will not repudiate a digital signature executed with an identity private key 

10 issued by its issuing participant 102; and (b) that the subscribing customer 106's certificate 
was valid at the time the signature was executed. 

In a preferred embodiment, to repudiate a digital signature in this context means to 
deny that a signature is genuine. A signature is genuine in this context if it is a signature of 
the subscribing customer on a digital transmission made in a representative capacity by the 

15 individual named in the digital certificate associated with the private key used to sign the 
transmission. 

In an altemative preferred embodiment, to repudiate a digital signature in this 
context means to deny that a signature is authorized. A signature is authorized in this 
context if, with respect to a digital transmission, the individual who made the digital 
20 signature of the subscribing customer on a digital transmission had actual authority to do so. 
Authorized in this context does not mean that the issuance or signing of the digital 
transmission or the execution or performance of any underlying transaction was or is 
rightfiil or proper. 

The warranted amount establishes the maximum dollar amount of recovery that a 
25 relying customer 108 may recover for damage suffered as a result of reliance on the 
warranty. As noted, this amount is preferably a maximum, i.e., the highest amount that 
relying customer 108 may recover. If the relying customer's damage is less than this 
maximum, then the relying customer preferably recovers only its actual damage. 

The claim period is the period during which relying customer 108 must file a claim 
30 linder the warranty in order to recover for any damage suffered. If no claim is filed within 
the claim period, the warranty expires, as described in more detail below. 

In a preferred embodiment, warranties expire at 22:00 GMT regardless of the time 
of day the warranty issued. For example, for a warranty issued with a claim period of 14 
days, 14 24-hour periods are counted from the time the warranty is issued, and the warranty 
35 expires at 22:00 GMT following that time. Thus, in this preferred embodiment, if, for 
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example, a warranty is issued on the first of the month at 2:00 PM Eastern Daylight Time, 
the warranty would expire at 22:00 GMT (i.e., 6:00 PM Eastern Daylight Time) on the 15^ 
of the month. By contrast, in this preferred embodiment, if, for example, a warranty is 
issued on the first of the month at 7:00 PM Eastern Daylight Time, the warranty would 

5 expire at 22:00 GMT on the 16'*' of the month. 

In an altemative embodiment, warranties may expire at 21 :00 GMT on the last day 
of the claim period regardless of the time of day the warranty issued, as described in U.S. 
provisional patent application serial No. 60/224,994, filed August 14, 2000, entitled Signing 
Interface CompUance Requirements, Smart Card Compliance Requirements, Warranty 

10 Service Functional Requirements, and Additional Disclosure, which is hereby incorporated 
by reference. 

In a preferred embodiment, warranties are issued by a participant in response to a 
request received firom a customei". The request preferably specifies the desired warranty 
amount and claim period. The participant and root entity 1 10 evaluate the request in light of 

15 a plurality of factors, described in more detail below, and determine whether or not the 
warranty should be issued. In a preferred embodiment, the warranty is requested by a 
subscribing customer 106 firom its issuing participant 102. In a preferred embodiment, the 
first party to the warranty contract is issuing participant 102 and the second party to the 
warranty contract is subscribing customer 106. Relying customer 108 is preferably a third- 

20 party beneficiary of the warranty contract with recourse against issuing participant 102 for 
monetary compensation up to the warranted amount. 

In a preferred embodiment, the operating rules establish a $500 minimum value for a 
warranty. In addition, issuing participant 102 may establish its own minimum value for 
warranties that it issues which may not be lower than that established by root entity 110. 

25 The system operating rules also preferably estabUsh a $100,000 maximxmi value for a 
warranty. In addition, issuing participant 102 may establish its own maximum value for 
warranties that it issues which may not be higher than that established by root entity 1 10. In 
a preferred embodiment, the operating rules require that the claim period of a warranty be 
one of: 7, 14, 30, 60, 90, or 180 days. 

30 

Warranty Caps 

In a preferred embodiment, in order to manage the liability risks associated with 
issuing warranties, root entity 1 10 uxiposes a series of limits, called participant warranty 
caps, on the warranty volume that each issuing participant may have outstanding. These 
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caps are intended to limit the aggregate level of operating risk exposure for individual 
participants and to limit the overall risk in the system. 

As used herein, the term 'Warranty volume" refers to the aggregate dollar amount of 
outstanding (i.e., unexpired) warranties issued by or for a system entity. Thus, for example, 
5 if an issuing participant has issued 500 warranties with warranted amounts of $500 each and 
200 warranties with warranted amounts of $10,000 each, then the participant's warranty 
volume is $2.25 M. In addition, as used herein, the term ^Svarranty cap utilization," when 
expressed as an amount of currency, refers to the warranty volume of an issuing participant 
102. When expressed as a percentage value, the term 'Svarranty cap utilization" refers to 
10 the participant's warranty volume divided by its warranty cap. 

As described below, in a preferred embodiment, a participant's warranty volume is 
compared to its participant warranty cap before a warranty is issued and the warranty is not 
issued if the warranted amount would push the issuing participant over its cap. 

A preferred embodiment for calculating a participant warranty cap for each issuing 
15 participant 102 is described below. Any reference in this document to a 'Warranty cap" 
refers to a participant warranty cap, unless otherwise specified. 

In a preferred embodiment, each issuing participant 102 may also establish a 
customer warranty cap for each of its subscribing customers 106, A customer warranty cap 
• limits the total warranty volume issued for a subscribing customer 106 that may be 
20 outstanding at any time, as described in more detail below. 

In a preferred embodiment, each issuing participant 102 may also establish an 
individual warranty cap for each employee of subscribing customer 106 that is authorized to 
act on the customer's behalf. An individual warranty cap limits the total warranty volume 
issued for an authorized individual that may be outstanding at any time, as described in 
25 more detail below. 

In a preferred embodiment, root entity 110 may also estabUsh a country-specific 
warranty cap. This warranty cap limits the warranty volume that all participants in a given 
country may have outstanding at any time. 

In a preferred embodunent, subscribing customer 106 may also estabUsh warranty 
30 caps for itself and its employees that limit the warranty volume that it or its employees may 
have outstanding at any time. Subscribing customer 106 conveys these warranty caps to its 
issuing participant which enforces them in its warranty-issuance process, as described in 
more detail below. 

35 Collateral 
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In a preferred embodiment, root entity 1 10 imposes collateral requirements on 
issuing participant 102 that may be used to pay claims for damages filed by relying 
customers if the issuing participant is unable or unwilling to satisfy a warranty claim. The 
collateral is preferably held by a third-party collateral agent that is contractually obligated to 
5 pay warranty claims firom a participant's collateral account if, pursuant to dispute resolution 
procedures described in more detail below, the participant is ordered to pay a warranty 
claim but is unable or unwilling to do so. A preferred embodiment for calculating collateral 
requirements for each issuing participant 102 is described in more detail below. 

10 Warranty-Issuance Process Flow 

A preferred embodiment of a warranty-issuance process flow is now described in 
connection with FIG. 3 and FIGs. 4-6. As will be recognized firom the description below, 
FIGs. 4-6 respectively cover distinct contingencies that may occur during operation of this 
preferred embodiment. In particular, FIG. 4 is directed to the case where a warranty is 
15 issued; FIG. 5 is directed to the case where a warranty is rejected by issuing participant 102; 
and FIG. 6 is directed to the case where a warranty is rejected by root entity 110. 

Before commencing the description of this preferred embodiment, a brief overview 
of the messages shown in FIGs. 4-6 is presented. Preferred specifications for each of these 
messages are described in more detail below. As shown in FIGs. 4-6, the system utilizes the 
20 following messages in the warranty-issuance process: 

(1) Wrequest: used by a customer to request a warranty; 

(2) Wproposed: used by issuing participant 102 to propose a warranty to root entity 

110; 

(3) Wconfirmation: used by root entity 1 10 to indicate approval of the terms of a 
25 proposed warranty; 

(4) Wauthorizedandissued: used by issuing participant 102 to indicate approval of a 
requested warranty and to confirm warranty issuance; and 

(5) WReject: used by issuing participant 102 and root entity 1 10 to indicate rejection 
of a warranty request. 

30 Turning to FIG. 3, in step 301, subscribing customer 106 visits relying customer 

108's Web site. The parties preferably authenticate themselves to each other over an SSL 
session with their utility keys. 

In step 302, Web server 220 communicates data to be digitally signed to browser 
224 (e.g., a purchase order for an agreed-to transaction). In step 303, the data to be signed is 

35 forwarded to smartcard subsystem 226 which signs the data. In step 304, the executed 
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digital signature is returned to browser 224. In a preferred embodiment, this signing process 
may be facilitated by using a signing interface 225 to invoke smartcard subsystem 226, as 
described in U.S. provisional application serial No. 60/224,994, filed August 14, 2000, 
entitled Signing Interface Requirements, Smart Card Compliance Requirements, Warranty 
5 Service Functional Requirements, and Additional Disclosure, which is hereby incorporated 
by reference. 

In step 305, software on the subscribing customer's computer creates a request for 
warranty and transmits the request to transaction coordinator 202^, of issuing participant 102 
(message 1 in FIGs. 4-6). In a preferred embodiment, this software may be implemented as 

10 a component of the signing interface. In an alternative embodiment, this software may be 
implemented as a component of smartcard subsystem 226. In yet another altemative 
embodiment, this software may be implemented as a plug-in to browser 224 or as a 
component of another suitable software program resident on the subscribing customer's 
computer. The warranty request is preferably digitally signed by subscribing customer 106. 

15 Upon receipt of the request for warranty, in step 306, transaction coordinator 202ip 

checks that the subscribing customer's digital certificate is valid. In a preferred 
embodiment, this step may be performed by validating the digital certificate with OCSP 
responder 204n>. If the digital certificate is not valid, processing proceeds to step 3 12, 
described below. • 

20 If the subscribing customer certificate is valid, then, in step 307, transaction 

coordinator 202n> forwards the request to its warranty manager 230ip for a determination as 
to whether issuing participant 102 may and/or should assume the liability associated with 
the warranty requested by subscribing customer 106 (message 2 in FIGs. 4-6). 

Warranty manager 230ip receives the warranty request message firom transaction 

25 coordinator 202ip and evaluates the warranty request both wdth respect to its internal risk 
management policies and with respect to the total value of warranties it has akeady 
extended. In particular, in step 308, warranty manager 230ip checks that the warranty 
request is for a permitted amount (i.e., not greater than any maximum specified by issuing 
participant 102 or root entity 110 and not less than any minimum specified by issuing 

30 participant 102 or root entity 1 10). If the request is not for a permitted amount, processing 
proceeds to step 312, described below. In step 309, warranty manager 230ip checks that the 
warranty request is for a permitted claim period (i.e., is" for one of 7, 14, 30, 60, 90, or 180 
days, in the preferred embodiment described above). If the request is not for a permitted 
claim period, processing proceeds to step 312, described below. 
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In step 310, warranty manager 230|p checks that the requested warranty amount will 
not cause any established warranty cap to be exceeded. Thus, warranty manager 230ip 
retrieves from memory the warranty cap utilization of issuing participant 102 and checks 
that the requested warranty amount will not cause its own participant warranty cap to be 
5 exceeded, as well as any other warranty caps (e.g., customer or individual warranty caps) 
established by itself or by subscribing customer 106. If the requested warranty would cause 
any established cap to be exceeded, then processing proceeds to step 312, described below. 

In step 311, warranty manager 230ip performs any other checks or risk management 
analysis put in place by issuing participant 102. For example, issuing participant 102 may 
10 implement fraud software that detects unlikely usage pattems for a digital certificate and 
denies a warranty when such a usage pattern is detected. If any such additional check fails 
or if any such analysis indicates that no warranty should be issued, processing proceeds to 
step 312, described below. 

If one or more of the above checks fail or if any other risk management process 
1 5 indicates that a warranty should not be issued, then, in step 312, warranty manager 230ip 
denies the requested warranty by transmitting a rejection message to transaction coordinator 
202ip (message 3.2 in FIG. 5). In step 313, transaction coordinator 202^, digitally signs the 
rejection message and forwards it to subscribing customer 106 (message 10.2 in FIG. 5). 
Otherwise, in step 314, warranty manager 230ip logs the terms of the requested 
20 warranty and transmits a proposed warranty to transaction coordinator 202ip (message 3. 1 in 
FIGs. 4, 6). In step 315, transaction coordinator 202n> digitally signs the proposed warranty 
and forwards it to transaction coordinator 202r (message 4 in FIGs. 4, 6). In step 316, 
transaction coordinator 202^ forwards the proposed warranty message to warranty manager 
230r (message 5 in FIGs. 4, 6). 
25 In step 317, warranty manager 230r checks that the warranty request is for a 

permitted amount (i.e., not greater than any maximum specified by root entity 1 10 and not 
less than any minimum specified by root entity 1 10). If the request is not for a permitted 
amount, processing proceeds to step 320, described below. In step 318, warranty manager 
230r checks that the warranty request is for a permitted claim period (i.e., is for one of 7, 
30 14, 30, 60, 90, or 180 days, in the preferred embodiment described above). If the request is 
not for a permitted claim period, processing proceeds to step 320, described below. 

In step 319, warranty manager 230^ retrieves from memory the warranty cap 
utilization of issuing participant 102 and checks that the requested warranty amount will not 
cause issuing participant 102's participant warranty cap to be exceeded, as well as any other 
35 warranty caps that it has established (e.g., country warranty caps). If the requested warranty 
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would cause any established cap to be exceeded, then processing proceeds to step 320, 
described below. 

If one or more of the above checks fail, then, in step 320, warranty manager 230^ 
denies the requested warranty by transmitting a rejection message to transaction coordinator 

5 202r (message 6.2 in FIG. 6), In step 321, transaction coordinator 202^ digitally signs the 
rejection message and forwards it to transaction coordinator 202ip (message 7.2 in FIG. 6). 
In step 322, transaction coordinator 202^, forwards the rejection message to warranty 
manager 230^ (message 8.2 in FIG. 6). In step 323, transaction coordinator 202ip 
formulates a rejection message and transmits it to subscribing customer 106 (message 10.2 

10 in FIG. 6). 

Otherwise, in step 324, warranty manager 230r logs the terms of the proposed 
warranty and generates a unique warranty identification (ID) number for the warranty. In 
addition, warranty manager 230r updates the issuing participant's warranty cap utilization to 
reflect the warranted amoimt. In step 325, warranty manager 230r generates a warranty 

15 confumation that includes the warranty identification number and transmits it to transaction 
coordinator 202r (message 6.1 in FIG. 4). In step 326, transaction coordinator 202^ 
digitally signs the warranty confirmation and forwards it to transaction coordinator 202ip 
(message 7.1 in FIG. 4). In step 327, transaction coordinator 202n> forwards the warranty 
confirmation to warranty manager 230^ (message 8. 1 in FIG. 4). In step 328, warranty 

20 manager 230ip logs the confirmation message and updates its warranty cap utilization to 
reflect the warranted amount. In step 329, warranty manager 230ip generates a warranty 
authorized and issued message comprising the terms of the warranty (message 9.1 in FIG. 4) 
and sends it to transaction coordinator 202ip. hi step 330, transaction coordinator 202n> 
digitally signs the warranty authorized and issued message and forwards it to subscribing 

25 customer 106 (message 10. 1 in FIG. 4). In step 331, subscribing customer 106 appends the 
signed warranty authorized and issued message to its digital signature and returns the signed 
transaction data to relying customer 108. 

In step 332, relying customer 108 prepares an OCSP request to validate the 
certificate of the system component that signed the warranty authorized and issued message 

30 (transaction coordinator 202ip in this preferred embodiment). In step 333, relying customer 
108 transmits the request to relying participant 104 for validation. The validation process 
may proceed in a manner analogous to that described in co-pending U.S. appUcation serial 
No. 09/657,605, filed September 8, 2000, entitled System and Method for Providing 
Certificate Validation and Other Services, which is hereby incorporated by reference. In 

35 particular the OCSP request may be transmitted to OCSP responder 204ip via transaction 
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coordinator 202,p. OCSP responder 204u> prepares and signs an OCSP response which is 
then returned to the relying participant via transaction coordinator 202u, In a preferred 
embodiment, this validation request may be bundled with a validation request for 
subscribing customer 106's certificate and the two requests may be jointly processed. 
5 In step 334, relying customer 108 receives the validation response from relying 

participant 104. If the validation is positive, relying customer 108 may be confident that the 
warranty is valid. 

In a preferred embodiment, root entity 110 may establish as an operating rule that a 
warranty issued in accordance with the above-described preferred embodiment is effective 

10 as soon as it is issued and that no validation is required to render the warranty enforceable. 
The operating mle may also preferably specify that if, at the time the warranty was signed, 
an OCSP request for the certificate of the system component that signed the certificate 
(transaction coordinator 202ip in this preferred embodiment, hereafter the * Warranty issuer'' 
or "issuer") would have resulted in a negative response, then the warranty is not 

15 enforceable. 

As will be recognized, in this preferred embodiment, the enforceability of the 
warranty does not tum on whether or not relying customer 108 actually requests validation 
of the issuer's certificate. Nevertheless, relying customer 108 may likely wish to validate 
the issuer's certificate before relying on the warranty because without such validation, 

20 relying customer 108 cannot be certain that the warranty will be enforceable. 

In addition to benefitting the relying customer, this validation may also facilitate 
business purposes important to system participants, including relying participant 104. In 
particular, since, as noted, relying customer 108 is typically a customer of relying 
participant 104, it may be desirable to provide relying customer 108 a strong motivation to 

25 continue to use services provided by relying participant 104, even in cases where a warranty 
issued by issuing participant 102 (of whom relying customer 108 is not necessarily a 
customer) is automatically enforceable without any action by rel3dng participant 108. This 
preferred embodiment facilitates these business purposes because, although the issued 
warranty (if valid when signed) is enforceable without any action by relying customer 108, 

30 relying customer 108 will nevertheless likely choose to utilize its relying participant's 
validation service to validate the warranty issuer's certificate to ensure that the warranty is 
enforceable. 

In an alternative preferred embodiment that also facilitates these business purposes, 
root entity 110 may establish an operating rule that a warranty issued in accordance with the 
35 above-described preferred embodiment does not go into effect until received by relying 
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customer 108. Proof of time of receipt may be established, for example, by timestamping 
the received warranty with a third-party timestamping service or by validating the warranty 
issuer's certificate and preserving the timestamped OCSP response. The operating rule may 
also specify that, if between the time that the warranty was issued by issuing participant 102 

5 and the time that the warranty was received by relying participant 108, the warranty issuer's 
certificate becomes invalid, then the warranty is unenforceable. 

In this preferred embodiment as well, when a relying participant 108 receives a 
warranty from a subscribing customer 106, it cannot be certain that the warranty will be 
enforceable against issuing participant 102 unless it confirms after receiving the warranty 

10 that the warranty issuer's certificate remains valid. Accordingly, relying participant 108 
will likely wish to validate the warranty issuer's certificate using its relying participant's 
validation service. 

As will be recognized, in this preferred embodiment as well, the validity of the 
issued warranty does not turn on whether or not relying customer requests validation of the 

15 warranty issuer's certificate. In particular, if the certificate is valid, the warranty will be 
enforceable even if the relying customer does not confirm its vaUd status. Similarly, if the 
warranty issuer's certificate is invalid, the warranty will not be enforceable even if the 
relying customer does confirm its invalid status. Thus, in the former case, the warranty is 
enforceable when received (although the relying customer may not know this for certain 

20 without validation) and does not require any action by the relying customer to render it 
enforceable. 

It should be recognized that although in the preferred embodiments described above, 
the warranty issuer is transaction coordinator 202ip, the warranty issuer may altematively be 
some other component v^th signing capability maintained by issuing participant 102. For 

25 example, if warranty manager 230ip is provided vnth digital signing capability (e.g., an 
HSM), then warranty manager 230ip may itself sign all warranty messages created by 
issuing participant lOSZ. Altematively, another system component with signing capability 
may be designated to sign all warranty messages created by issuing participant 102. 

In addition, as noted above, although the preferred embodiments described above 

30 employs transaction coordinators at each participant 102, 104 and at root entity 1 10, it 
should be noted that, in an alternative embodiment, the system may be designed v^thout 
some or all of these transaction coordinators. In this alternative embodiment, messages 
created, signed, or transmitted by, to, or via a transaction coordinator in the foUov^g 
description, may instead be created, signed, or transmitted by, to, or via a substitute system 

35 component adapted to comprise appropriate hardware and/or software to provide the desired 
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functionality. Thus, for example, the system may be designed so that OCSP requests from a 
relying customer 108 are transmitted directly to OCSP responder 204ip by the customer's 
relying participant 104 and warranty messages to or from an issuing participant 102 are 
transmitted directly to or from that participant's warranty manager 230jp. 

5 

Warranty Claim Procedure 

In a preferred embodiment, relying customer 108, as a third-party beneficiary, may 
bring a claim against an issuing participant 102 if a warranted fact in a warranty issued by 
the participant is incorrect, and the relying customer suffers damage as a result of its 
10 reliance on the warranted fact. A preferred embodiment of a process for filing and resolving 
warranty claims is now described in connection with FIG. 7 and FIG. 8. 

Before commencing description of this preferred embodiment, a brief overview of 
the messages shown in FIG. 8 is presented- Preferred specifications for each of these 
messages are described in more detail below. As shownti in FIG 8, the system utilizes the 
15 following messages in the warranty-claim process: 

(1) WCRequest: used by a relying customer 108 to file a claim against a 

warranty; 

(2) WCNotification: used by a relying participant 104 to notify an issuing 
participant 102 and root entity 1 10 of a filed claim; 

20 (3) WCResponse: used by an issuing participant 102 to acknowledge receipt 

of a filed claim; 

(4) WCAck: used by root entity 1 10 to acknowledge receipt and processing 
of a filed claim. 

As shown in FIG. 7, in step 701, relying customer 108 files a warranty claim with 
25 relying participant 104 by transmitting a WCRequest message to transaction coordinator 
202rp of relying participant 104 (message 1 in FIG. 8). Relying customer 108's claim must 
preferably include the terms of the warranty (as specified in the warranty-authorized-and- 
issued message), the date of the claim, and the warranty claim amount. 

In step 702, relying customer 108 provides relying participant 104 with an affidavit 
30 certified by a duly authorized person on behalf of relying customer 108 that includes 

complete and detailed supporting documentation certifying the amount of damages claimed 
by relying customer 108. Relying customer 108 also provides relying participant 104, to the 
extent available, vmtten documentation from subscribing customer 106 identifying the 
particular warranted fact that is alleged to be incorrect. For example, the vmtten 
35 documentation from subscribing customer 106 may include a statement denying that it 
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authorized a particular digital signature or acknowledging that its certificate was not valid at 
the time of the transaction. In a preferred embodiment, the documentation submitted in this 
step must be submitted vvithin 14 days of the warranty-claim filing. 

In an alternative embodiment, relying customer 108 may submit its claim and 

5 supporting documentation directly to issuing participant 102, In this embodiment, the 
warranty-authorized-and-issued message preferably comprises information to aid relying 
customer 108 in filing its claim. This information may include a uniform resource locator 
(URL) that identifies a Web page that contains further claim-processing information and a 
mailing address for submitting supporting documentation. If relying customer 108 files its 

10 claim directly with issuing participant 102, then it preferably provides relying participant 
104 with copies of the documentation it files. 

In step 703, relying participant 104 notifies issuing participant 102 and root entity 
1 10 of the filed claim by transmitting a WCNotification message to transaction coordinatpr 
202n. of issuing participant 102 and transaction coordinator 202r of root entity 1 10 

15 (messages 2, 3 in FIG. 8). Transaction coordinators 202ip, 202r forward the notifications to 
their respective warranty managers 230ip, 230r (messages 2.1, 3.1 in FIG. 8). In a preferred 
embodiment, these notifications must be made within twenty-four hours of the time relying 
participant 104 receives information regarding the filed claim. The notification preferably 
includes the warranty ID for the warranty that is the subject of the warranty and the warranty 

20 claim amount. 

In step 704, warranty manager 230ip of issuing participant 102 acknowledges receipt 
of the warranty claim by transmitting a WCResponse message to relying participant 104 via 
transaction coordinator 202ip (messages 2.2, 2.3 in FIG. 8). In step 705, transaction 
coordinator 202rp of relying participant 104 forwards the message to relying customer 108 

25 (message 4 in FIG. 8). 

In step 706, warranty manager 23 Or of root entity 110 checks the warranty-claim 
amount to confirm that it is not greater than the warranted amount and that the date of the 
claim precedes the warranty expiration date. If both of these conditions are satisfied, then 
warranty manager 230r marks the warranty as "claimed" (step 707), Otherwise, the 

30 warranty claim is rejected (step 708). In step 709, warranty manager 230r releases the 
amount of the claim fi-om issuing participant 102's warranty cap utilization. In a preferred 
embodiment, this release is performed 48 hours after a warranty is designated as "claimed.*' 

In a preferred embodiment, if a claim is filed for less than the fiill amount of the 
warranty, then the unclaimed amount is treated as still utilized under an issuing participant's 

35 warranty cap. For example, if issuing participant 102 issues a warranty for $500,000 and a 
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claim is filed for $200,000, then $200,000 is released from issuing participant 102's 
warranty cap utilization, thus becoming available for writing additional warranties. The 
remaining $300,000 continues be considered as utilized warranty cap, and is not released 
until the warranty expiration date. If during the warranty claim period, claims for additional 
5 losses are made against the remaining amount of the warranty, then the amount of those 
additional claims may at that time be released from issuing participant 102's warranty cap 
utilization. 

In step 710, root entity places a hold on issuing participant 102's collateral account 
for the claimed amount to cover the claim in the event issuing participant 102 defaults. In 

10 step 711, warranty manager 230r of root entity 110 acknowledges receipt and processing of 
the warranty claim by transmitting a WCAck message to relying participant 104 via 
transaction coordinator 202^ (messages 3.2, 3.3 in FIG. 8). 

In step 712, issuing participant 102 examines the claim and any supporting 
documentation and determines whether it will pay the claim. If issuing participant 102 

15 determines to pay the claim, then, in step 713, issuing participant 102 transfers sufficient 
fiinds to cover the amount of the claim to relying participant 104 for the benefit of relying 
customer 108. Relying participant 104 preferably notifies root entity 1 10 via a daily 
reporting procedure established by root entity 110 once relying participant 104 has received 
these funds. Once root entity 110 receives this notification, warranty manager 230^ releases 

20 the hold on issuing participant 102's collateral account for the amount of claim paid. 

If issuing participant 102 determines not to pay the claim, then, in step 714, issuing 
participant 102 and relying customer 108 proceed to dispute resolution to resolve the claim. 
An exemplary set of dispute resolution procedures is set forth in U.S. provisional 
application serial No. 60/153,443, filed September 10, 1999, entitled System and Process 

25 for Certification in Electronic Commerce, converted into co-pending U.S. patent 

application serial No. 09/657,623, filed September 8, 2000, entitled System and Method for 
Providing Certificate-Related and Other Services, both of which are hereby incorporated by 
reference. Root entity 110 preferably does not release collateral held to secure a disputed 
warranty claim until the dispute is successftiUy resolved. 

30 The claims procedure described above is fiirther described in U.S. provisional 

application serial No, 60/153,443, filed September 10, 1999, entitled System and Process 
for Certification in Electronic Commerce, converted into co-pending U.S. patent application 
serial No. 09/657,623, filed September 8, 2000, entitled System and Method for Providing 
Certificate-Related and Other Services, both of which are hereby incorporated by reference. 

35 
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Warranty Cap Calculation and Daily Processing 

As noted, in a preferred embodiment, root entity 110 imposes a warranty cap on 
each issuing participant 1 02 that Hmits the warranty volume the participant may have 
outstanding at any point in time. These caps are intended to control the aggregate level of 
5 operating risk exposure for individual participants and to control the overall risk in the 
system. 

In a preferred embodiment, warranty manager 230r of root entity 1 10 is tasked with 
establishing each issuing participemt's warranty cap and adjusting the cap as appropriate. 
Warranty manager 230r preferably takes into account a plurality of factors in calculating a 

10 participant warranty cap, including the participant's total capital, operating loss factor, and 
credit rating. The credit rating is preferably queintified as a credit discount factor so that it 
may be incorporated in the warranty-cap calculation, as described below, hi addition, as 
noted below, a participant may raise its warranty cap by submitting credit-based collateral to 
a collateral agent to cover potential warranty claims. 

1 5 One preferred embodiment for calculating a participant warranty cap is: 

Participant Warranty Cap= (Total Capital * (1 /Operating Loss Factor) * Credit Discount 

Factor) + (Credit-Based Collateral) 

20 In a preferred embodiment, total capital represents the capital level of the legal entity 

under which a participant's certification authority operates (i.e., the entity that signs 
customer certificates). For example, if a participant operates its certification authority under 
an operating subsidiary, then the capital level of the subsidiary is used to determine the 
participant warranty cap. But if the issuing participant operates its certification authority as 

25 part of its main financial services entity, then the total capital of that entity is used to 
determine the participant warranty cap. 

The operating loss factor preferably represents the historical operating loss of the 
issuing participant for operations within the present system. As will be recognized, when a 
participant first commences operation in the present system, it caimot immediately be 

30 assigned an actual operating loss factor, since there is no historical data fi-om which to 
calculate it. Accordingly, in a preferred embodiment, all participants are initially assigned 
an estimated operating loss factor of 0.6% derived in the chart below. 



35 
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5 



10 



Bank Operating Loss 


16-25 bps 


First Manhattan estimates based on 
historical operating experience in 
processing businesses (1993-94) 


Mutual Fund Operating 
Losses 


40-50 bps 


First Manhattan estimates; Mutual 
Fund industry reports on reporting and 

processing anomalies (1993-94) 


Average 


30 bps 




Conservative Add-on 


2x 


Estimates 


Initial Operating Loss 
Factor 


60 bps 





Over time, the operating loss factor is preferably adjusted as actual operating loss data 
becomes available, hi a preferred embodiment, a participant's operating loss factor is 
15 adjusted annually to reflect the participant's actual operating loss for the most recent year. 
As noted, each participant's credit rating is preferably translated into a credit 
discount factor. An exemplary set of credit ratings and associated discount factors are set 
forth below: 



20 



25 







AAA(-0+) 


1.0 


AA(-0+) 


1.0 


A(-0+) 


0.9 


BBB + 


0.8 


<BBB+ 


not eligible without 
explicit coUateralization of 
operations (credit-based 
collateral) 



An exemplary calculation of a participant warranty cap is illustrated below. 

Component (Millions) 



- Capital $2,000 

- Operating Loss Rate 0.60% 
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- Credit Rating (Discount Factor) AA(LO) 



Total Warranty Cap 



$333,333 



5 In a preferred embodiment, root entity 110 may initially establish a participant 

warranty cap of $50,000,000 for each participant when the system is first established. The 
above warranty-cap formula may then preferably be phased in as system entities gain 
operational experience. 

Once a warranty cap is set for a particular participant, the participant's warranty 

10 volume may not exceed the cap. As noted, warranty manager 23 Or preferably tracks each 
issuing participant's warranty cap utilization and checks each time a warranty is proposed to 
ensure that the participant's cap will not be exceeded. In addition, warranty manager 230r 
may check an issuing participant's warranty cap utilization against its participant warranty 
cap at predetermined intervals, such as daily. If a participant exceeds its warranty cap, then 

15 root entity 1 10 may take reasonable steps to address the situation, including but not limited 
to, fining the participant or suspending its certificate. 

In a preferred embodiment, warranty manager 230r is adapted to report to 
participants their warranty cap utilization and outstanding warranty claims on a regular 
basis. The reporting firequency may preferably be a function of the percentage of a 

20 participant's warranty cap that is currently being utilized. One preferred embodiment of a 
reporting schedule is as follows: 



25 




Less than 80% of Warranty 
Cap 



80-90% of Cap 



Greater than 90% of Cap 



4 hours 



Real Time 



30 



Collateral Requirement Calculation and Pail v Processing 

As noted, in a preferred embodiment, root entity 110 imposes collateral 
requirements on each issuing participant 102 that may be used to pay claims for damages 
filed by relying customers if the issuing participant is unable or unwilling to satisfy such 
35 claims. Although the amount of required collateral need not be adequate to ensure full 
coverage of all outstanding warranties, the collateral amount is preferably adequate to 
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materially increase the probability of a relying customer's recovery on a warranty claim in 
the event that an issuing participant is unable or unwilling to honor such a claim. 

In a preferred embodiment, the total collateral amount posted by an issuing 
participant 102 is made up of two components: performance-based collateral and credit- 
5 based collateral. In a preferred embodiment, the performance-based collateral requirement 
for an issuing participant 102 may be calculated as follows: 

Performance-Based Collateral Requirement = [Warranty Volume Outstanding * Operating 
Loss Factor] + [Aggregate Amount of Outstanding Unpaid Warranty Claims] 



All system participants are preferably required to post performance-based collateral. 

Credit-based collateral is collateral that an issuing participant chooses to post in 
order to increase its warranty cap. If a participant elects to post credit-based collateral, then 
it is preferably required to maintain the credit-based collateral until it changes its election 

15 and its warranty cap no longer includes the credit-based collateral. 

An exemplary calculation of the required collateral amount for an issuing participant 
102 is illustrated below. For purposes of this example, it is assumed that issuing participant 
102 has $500 million in issued warranties, an operating loss factor of 0.6%, and outstanding 
warranty claims of $200,000. As such, issuing participant 102 must maintain in this 

20 preferred embodiment a minimimi of $3.2 million in performance-beised collateral for the 
benefit of relying customers in the event of default on a warranty claim. As further assumed 
in the example below, if issuing participant 102 wishes to post an additional $2 million in 
credit-based collateral to increase its warranty cap, then its total required collateral amount 
would be $5,2 million. 



10 



25 



Component 

(a) Outstanding Claims (100%) 

(b) Warranties Issued 



$(miIlions) 
$.20 



$500 



30 (c) Operating Loss Rate 

(d) Projected Claims Rate (b*c) 
Performance-Based Collateral 



0.60% 



$3.00 
$3,20 



(a+d) 

Credit-Based Collateral 
35 Total Required Collateral 



$2.00 



$5.20 
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In a preferred embodiment, root entity 1 10 designates the types of collateral (called 
eligible collateral) that may be posted by participants in satisfaction of the collateral 
requirements described above. In one preferred embodiment, the only eligible collateral are 
5 U.S. dollars and direct obligations of the U.S. government (e.g., U.S. treasury securities). In 
other preferred embodiments, root entity 1 10 may establish additional types of eligible 
collateral. 

In a preferred embodiment, each issuing participant selects its own collateral agent 
for purposes of administering collateral that it must post. Each issuing participant 
10 preferably establishes a collateral account with its collateral agent specifically for the 
collateral posted in satisfaction of these collateral requirements. Preferably, credit-based 
collateral is held in a separate account than performance-based collateral. 

In a preferred embodiment, the collateral agent is subject to a contractual obligation 
under which it may be directed to pay a warranty claim from a participant's collateral 
15 account if that participant refuses to pay the claim. Payment may preferably be directed 
from both credit-based collateral and performance-based collateral to satisfy a claim. 

In a preferred embodiment, root entity 110 updates each issuing participant's 
collateral requirements and monitors the participant for compliance with those requirements 
on a regular basis, preferably daily. A preferred updating and monitoring process is now 
: .20 described in connection with FIG. 9. 

As shown in FIG. 9, in step 901, the collateral agent calculates a value for the 
collateral posted with it by issuing participant 102, In performing this calculation, the 
collateral agent preferably uses reliable pricing sources to obtain closing market prices of 
each security included in the collateral. In a preferred embodiment, the collateral value is 
25 calculated as the sum of the market values of each security included in the collateral 
multiplied by a haircut for that security preferably determined by root entity 110. Any 
collateral that is not eligible collateral is preferably assigned a market value of zero in this 
valuation. 

In step 902, the collateral agent transmits the calculated collateral value to root entity 
30 1 10. In step 903, root entity 110 calculates the issuing participant's required collateral 
amount. 

In step 904, root entity 110 calculates a delivery amount or retum amount for the 
issuing participant and notifies the issuing participant of its required collateral amount and 
this delivery amount or return amount. A delivery amount is the amount, if any, by which 

35 
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the required collateral amount exceeds the collateral value. A return amount is the amount, 
if any, by which the collateral value exceeds the required collateral amount. 

If root entity 1.10 notifies the participant of a delivery amount, then, in step 905, the 
issuing participant must deliver eligible collateral with a collateral value at least equal to 
5 that delivery amount to its collateral agent. Failure to satisfy this requirement within one 
business day is grounds for suspension of the participant. Otherwise, if root entity 110 
notifies the participant of a return amount, then, in step 906, the participant may elect to 
request the return of collateral with a collateral value no greater than the retum amount fi-om 
its collateral agent. 

10 

Warranty Manager Implementation 

In a preferred embodiment, warranty manager 230 is implemented as a database 
application. If desired, warranty manager 230 may be designed as a true message 
processing application with a messaging queue 235 and other message processing 
15 capabilities as shown, for example in FIG, 10. Alternatively, warranty manager 230 may be 
designed as a function call processing appUcation with no messaging support as shown in 
FIG. 11. 

In a preferred embodiment, warranty manager 230 comprises a warranty manager 
API 240. API 240 is preferably estabUshed by root entity 110 and adapted to process all 
20 warranty messages exchanged between a warranty manager 230 and a transaction 
coordinator 202. 

In a preferred embodiment, API 240 is adapted to handle extensible markup 
language (XML) warranty messages, although other warranty message formats may be 
supported. API 240 is preferably adapted to enable warranty manager 230 to accept an 
25 XML warranty message, parse the contents of the message, and generate a new XML 

message as output. In order to simplify message processing, warranty manager API 240 is 
preferably adapted to use a different function to process each of the warranty messages 
described below. 

In a preferred embodiment, API 240 is implemented in C-H-. Altematively, if 
30 implemented in Java, API 240 preferably follows the same class and method stmcture as the 
C++ implementation described below. 

In a preferred embodiment, API 240 is implemented as a single inheritance C++ 
class derived fi-om a generic CObject class with appropriate public methods. All API 
functions retum a boolean value of TRUE if successful, otherwise they return FALSE. 

35 
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In a preferred embodiment, API 240 is adapted to accept a parameter that sets the 
environment in which warranty manager 230 operates. The operating environment of 
warranty manager 230 preferably corresponds to the entity at which warranty manager 230 
is implemented. Thus, for example, when initializing or communicating with warranty 
5 manager 230^ at root entity 1 10, this parameter is preferably set to a first value and when 
initializing or communicating with a warranty manager 230^. at an issuing participant 102, 
this parameter is preferably set to a second value. 



A preferred embodiment of API 240 is as follows: 



10 



typedef stmct xmlmsg 
{ 



char* buffer; // buffer is sufficiently large to hold entire message 

}; 



15 



class CWarrantyManager : public CObject 



{ 



public: 



20 



CWarrantyManager (char startupType) 



BOOL WMVersion (imsigned short *vmajor, unsigned short 
*vminor, char *IPorIR); 



25 



BOOL WMAlive(void); 



BOOL WMLastError(unsigned errCode, char* errTxt); 



30 



BOOL IPRequest (xmlmsg *m2, xmlmsg *m3); 



BOOL IRRequest (xmhnsg *m5,xmlmsg *m6); 



BOOL IPValidationReport (xmhnsg ipvm); 



35 



-26- 



NY2- 127251 IJ 



BOOL IRValidationReport (xmlmsg irvm); 



. BOOL IPWC(xmlmsg ipwcNotify, xmlmsg ipwcResp); 



5 



BOOL RTWC(xmlmsg rtwcNotify, xmlmsg rtwcAck); 



}; 



CWarrantyManager::CWarrantyManager 



10 



Constructor. Preferably there is only one instance of warranty manager 230 running 
CWarrantyManager( 



15 



char startup Type 



// Sets the environment in which this warranty 
manager instance runs 



); 



Parameters 

20 startupType character indicating "IP" for issuing participant 102 or "IR" for root entity 110. 
CWarrantyManager: :WMVersion 

Returns the version of the warranty manager code that is instantiated in this instance of 
25 warranty manager 230. 



BOOL WMVersion( 



unsigned short *vmajor, 
unsigned short *vniinor. 



// major version number 
// minor version number 



30 



char *PorIR 



// startup type character 



); 



3^ Parameters 
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vmajor major version number 
vminor minor version number 

IP orlR character indicating "IP" for issuing participant 102 or "IR" for root entity 110. 



5 CWarrantyManager : rWMAlive 



Returns boolean TRUE if this instance of warranty manager 230 is responding. 
BOOL WMAHveO; 

10 Parameters 



none 

CWarrantyManager: iWMLastError 

15 

Returns the last known error code of warranty manager 230. These error codes are 
implementor specific. 

BOOL WMLastError( 



20 



unsigned *errCode, 
char *errTxt, 

); 



// numeric error code 
// pointer to text buffer 



25 



Parameters 

errCode 
erTxt 



pointer to buffer for receiving numeric error code 

pointer to a buffer that will hold the returned error text. Returned text not to 
exceed 1024 bytes. 



30 CWarrantyManager: :IPRequest 



Posts a warranty request message to warranty manager 230n>. This call returns FALSE if the 
CWarrantyManager startup type is "JR." 
BOOL IPRequest( 

35 
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xmlmsg *m2, 
xmlmsg *m3. 



// pointer to input message 
// pointer to output message 



5 Parameters 

m2 Pointer to xmlmsg structure holding the input message 
m3 Pointer to xmlmsg 

CWarrantyManagerrilRRequest 

10 

Posts a proposed warranty request message to warranty manager 230^. This call retums 
FALSE if the CWarrantyManager startup type is "IP." 
BOOL IRRequest( 

15 xmlmsg *m5, // pointer to input message 

xmlmsg *m6, // pointer to output message 

); 

Parameters 

20 m5 Pointer to xmlmsg structure holding the input message 
m6 Pointer to xmlmsg structure to receive the output message 

CWarrantyManager::IPVaIidationReport 

25 Posts an issuing participant identity validation reporting message to warranty manager 230ip. 
This call should return FALSE if the CWarrantyManager startup type is "IR." 
BOOL IPValidationReport( 

xmlmsg *ipvm, // pointer to input message 

30 ). 

Parameters 

ipvm Pointer to xmlmsg structure holding the input message 

35 
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CWarrantyManager::IRVaIidationReport 



Posts a root entity identify validation reporting message to warranty manager 230^. This 
call returns FALSE if the CWarrantyManager startup type is "IP." 
5 BOOL rRValidationReport( 

xmlmsg *irvm, // pointer to input message 

); 

10 Parameters 



irvm Pointer to xmlmsg structure holding the input message 



CWarrantyManager: :IPWC 

Posts a warranty claims message to warranty manager 230ip. This call returns FALSE if the 
CWarranty Manager startup type is "IR." 
BOOL IPWC( 



20 

xmlmsg *ipwcNotify, // pointer to input message 

xmlmsg *ipwcResp, // pointer to output message 

); 



25 CWarrantyManager::RTWC 



Posts a warranty claims message to warranty manager 230r. This call returns FALSE if the 
CWarrantyManager startup type is "IP." 
BOOLRTWC( 



30 



xmlmsg *rtwcNotify, 
xmlmsg *rtwcAck, 

); 



// pointer to input message 
// pointer to output message 



35 
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Warranty Messages Specification 

As noted above, in a preferred embodiment, the following messages are used in the 
warranty-issuance process: (1) a warranty request message (Wrequest), (2) a warranty 
proposed message (Wproposed), (3) a warranty confirmation message (Wconfirmation), (4) 
5 a warranty authorized and issued message (Wauthorizedandissued), and (5) a warranty 
reject message (WReject). 

In addition, the following messages are used in the warranty-claim process: (1) a 
warranty claim request message (WCRequest), (2) a warranty claim notification message 
(WCNotification), (3) a warranty claim response message (WCResponse), and (4) a 
10 warranty claim acknowledgment message (WCAck). 

The following messages are used to report the daily number of certificate validations 
performed by an issuing participant: an issuing participant identity validation reporting 
message (WIPValidationReporting) and a root entity identity validation reporting message 
(WIRValidationReporting). 
15 The following message is used to report errors in the warranty process: a warranty 

error message (Werror). 

The following message is used to report a warranted transaction that has been 
canceled: a warranty canceled message (Wcanceled). 

In a preferred embodiment, all warranty messages are defined according to a 
20 document type definition (DTD). Root entity 110 preferably establishes a common DTD 
for system entities. The DTD provides the formal description of all valid XML warranty 
messages used in the system. Hence, system entities may use the DTD to verify that the 
messages they transmit and receive are valid. A preferred embodiment of a suitable DTD is 
described below. 

25 In a preferred embodiment, a complete XML warranty message comprises an XML 

declaration, a DTD reference, an XML namespace attribute (xmlns), and a set of data 
elements. An exemplary XML declaration is as follows: 

<?xml version="LO" encodings" UTF-8"?> 
30 < !— Root Entity Warranty Manager Version 1 .0 --> 
<!— Warranty Manager DTD — > 

An exemplary DTD reference is as follows: 

35 <!DOCTYPE WRequest PUBLIC 
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7/Root Entity/AVARRANTY MANAGER DTD//EN" "WaiTanty.dtd"> 



In a preferred embodiment, an xmlns attribute is used to identify the top-level entity 
in the DTD, i.e., root entity 110. This is done to prevent conflicts between names used in 
5 the warranty-message DTD and other DTDs. The value of the xmlns attribute is preferably 
fixed and may, for example, be set to "http://www.nameofrootentity.com". An exemplary 
warranty-message DTD definition of the xmlns attribute is as follows: 

<!ATTLIST WarrantyRequest 
10 xmlns CDATA #FIXED "http: //www. rootentityxom" 

> 

A preferred implementation of the data elements included in the above-described 
XML messages are now described, 
15 FIG. 12 illustrates the data elements used to construct warranty messages in a 

preferred embodiment of the present system. FIG. 13 provides descriptions and restrictions 
for each data element in this preferred embodiment. 

A warranty request message preferably includes the following data elements: 

• Warranty Request Message Code (indicating that the message is a warranty 
20 request) 

• Warranty Amount 
Warranty Currency Type 

• Warranty Claim Period 

• Relying Customer Name and Identifier 

25 • Subscribing Customer Name and Identifier 

• Subscribing Customer Transaction ID 

• Relying Customer Transaction ID 

Timestamp (with acceptable variance of ±/- 5 minutes from root entity 110 
time) 

30 In a preferred embodiment, the warranty request message may not include any other 

information, such as the contents of the underlying transaction. A preferred XML 
implementation for the data elements of this message is: 

<WRequest> 

35 <WAmount Currency="USD">100000</WAmount> 
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<WClaimPeriod Days="14" /> 
<RCNameAndId> 
<X509IssuerSerial> 

<X509IssuerName>CN=LlBl Certificate Authority, OU=Root Entity, 0=Root Entity, 
5 C=US</X509IssuerName> 

<X509SerialNumber>979827336</X509SerialNumber> 
</X509IssuerSerial> 
</RCNameAndId> 
<SCNameAndId > 
1 0 <X509IssuerSerial> 

<X509IssuerName>CN=LlB2 Certificate Authority, OU=Root Entity, 0=Root Entity, 
C=US</X509IssuerName> 

<X509SerialNumber>9 1 8827438</X509SerialNumber> 
</X509IssuerSerial> 
15 </SCNameAndId > 

<SCTransactionId Id="12345631232131678387589" /> 
<RCTransactionId Id="65432855775334990885891" /> 
<WRTimestamp DateTime="20000812163000Z" /> 
<yWRequest> 

20 

A warranty proposed message preferably includes the following data elements: 

• Warranty Proposed Message Code (indicating that the message is a proposed 
warranty) 

• Warranty Amount 

25 • Warranty Currency Type 

• Warranty Claim Period 

• Subscribing Customer Transaction ID 

• Relying Customer Transaction ID 

• Timestamp 

30 • Issuing Participant Name and Identifier 

• Warranty Alternate Currency Amount 
Warranty Alternate Currency Type 

35 A preferred XML implementation for the data elements of this message is: 
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<WProposeci> 

<WAmount CuiTency="USD">l 00000<AVAmount> 
<WClainiPeriod Days="14"/> 

<SCTransactionId Id="12345631232131678387589" /> 
5 <RCTransactionId Id="65432855775334990885891" /> 
<WRTimestamp DateTime="20000812163000Z"/> 
<IPNameAndId> 
<X509IssuerSerial> 

<X509IssuerName>CN=ROOT Certificate Authority, OU=Root Entity, 0=Root Entity, 
10 C=US</X509IssuerName> 

<X509SerialNumber>9 1 6627 1 88</X509SerialNumber> 
</X509IssuerSerial> 
</IPNameAndId> 

<WAlteniateAmoimtCurrency="GBP">140000<AVAlternateAmount> 
15 <yWProposed> 

A warranty confirmation message preferably includes the following data elements: 

• Warranty Confirmation Message Code (indicating that the message is a 
20 confirmation of a proposed warranty) 

• Warranty ID 

• Warranty Amount 

• Warranty Currency Type 

• Warranty Claim Period 

25 • Subscribing Customer Transaction ID 

Relying Customer Transaction ID 

• Timestamp 

• Issuing Participant Name and Identifier 

• Warranty Altemate Currency Amount 
30 • Warranty Altemate Currency Type 

• Warranty Expiration Date and Time 

A preferred XML implementation for the data elements of this message is: 
35 <WConfinnation> 
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<WarrantyId Id="9876540123XXXX" /> 

<W Amount Currency="USD"> 1 OOOOCK/W Amount> 

<WClaimPeriod Days="14"/> 

<SCTransactionId Id="12345631232131678387589" /> 
5 <RCTransactionId Id="65432855775334990885891 " /> 
<WRTimestamp DateTime="200008 1 2 1 63030Z"/> 
<IPNameAndId> 
<X509IssuerSerial> 

<X509IssuerName>CN=ROOT Certificate Authority, OU=Root Entity, 0=Root Entity, 
10 C=US<yX509IssuerName> 

<X509SerialNuniber>9 1 6627 1 88<yX509SerialNumber> 
</X509IssuerSerial> 
</IPNameAndId> 

<W Alternate Amount Currency="GBP"> 1 40000<AVAltemateAmount> 
1 5 <ExpiryDate DateTime="200022 1 2090000Z"/> 
</ WConfirmation > 



A warranty authorized and issued message preferably includes the following data 
elements: 



35 



30 



25 



Warranty Authorized and Issued Message Code (indicating that the message 

indicates warranty approval and issuance) 

Warranty ID 

Warranty Amount 

Warranty Currency Type 

Warranty Claim Period 

Relying Customer Name and Identifier 

Subscribing Customer Name and Identifier 

Subscribing Customer Transaction ID 

Relying Customer Transaction ID 

Timestamp 

Issuing Participant Name and Identifier 
Warranty Altemate Currency Amount 
Warranty Altemate Currency Type 
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Warranty Expiration Date and Time 



A preferred XML implementation for the data elements of this message is: 

5 <WAuthorizedAndIssued > 

<WarrantyId Id="9876540 1 23XXXX" /> 
<W Amount Currency="USD"> 1 00000<AVAmount> 
<WClaimPeriod Days="147> 
<RCNameAndId> 
10 <X509IssuerSerial> 

<X509IssuerName>CN=LlBl Certificate Authority, OU=Root Entity, 0=Root Entity, 
C=US</X509IssuerName> 

<X509SerialNumber>979827336</X509SerialNumber> 
</X509IssuerSerial> 
15 </RCNameAndId> 
<SCNameAndId > 
<X509IssuerSerial> 

<X509IssuerName>CN=LlB2 Certificate Authority, OU=Root Entity, 0=Root Entity, 
C=US</X509IssuerName> 
20 <X509SerialNumber>91 8827438</X509SerialNumber> 
</X509IssuerSerial> 
</SCNameAndId > 

<SCTransactionId Id="1234563 123213 1678387589" /> 
<RCTransactionId Id="65432855775334990885891" l> 
25 <WRTimestamp DateTiine="20000812163000Z"/> 
<IPNameAndId> 
<X509IssuerSerial> 

<X509IssuerName>CN=ROOT Certificate Authority, OU=Root Entity, 0=Root Entity, 
C=US</X509IssuerName> 
30 <X509SerialNumber>9 1 6627 1 88<;/X509SerialNumber> 
</X509IssuerSerial> 
<;/IPNameAndId> 

<W Alternate Amount Currency="GBP"> 1 40000<AVAltemate Amount> 
<ExpiryDate DateTime="200022 1 2090000Z"/> 
35 <yWAuthorizedAndIssued> 



-36- 



NY2- 127251 I.I 



A warranty reject message preferably includes the following data elements: 

Warranty Rejected Message Code (indicating that the message is a warranty 
rejection) 

• Reason Code and Text 

5 • Subscribing Customer Transaction ID 

• Relying Customer Transaction ID 

• Timestamp 

A preferred set of reason texts for this message when the message is generated by 
10 issuing participant 102 is: 

• Please contact your relationship manager. 

• Subscribing customer 106 exceeds warranty cap. 
Issuing participant 102 is unable to issue a warranty. 

Issuing participant 102 will review warranty request. Please resubmit after 24 
15 hours. 

• Issuing participant 102 will review warranty request. Please resubmit after 48 
hours. 

Issuing participant 102 will review warranty request. Please resubmit after 72 
hours. 

20 • Subscribing customer 106 not known/not a customer of the issuing 

p2irticipant 102. 

• Subscribing customer 106 certificate revoked or suspended. 

A preferred set of reason texts for this message when the message is generated by 
25 root entity 1 10 is: 

• Issuing participant exceeds warranty cap. 

• Root entity is unable to verify issuing participant status. 

A preferred XML implementation for the data elements of this message is: 

30 

<WReject Code="200" Reason="Issuing Participant exceeds warranty cap"> 
<SCTransactionId Id=" 1234563 123213 1678387589" /> 
<RCTransactionId Id="65432855775334990885891" /> 
<WRTimestamp DateTime="200008 1 2 1 63050Z"/> 
35 <AVReject> 
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FIG. 14 illustrates the data elements used to construct warranty claim messages in a 
preferred embodiment of the present system. 

A warranty claim request message preferably includes the following data elements: 

• Warranty Claim Request Message Code (indicating that the message is a 
warranty claim request) 

Warranty Authorized and Issued Message Received from Subscribing 
Customer 

• Claim Amount 
Claim Currency Type 

• Timestamp 

A preferred XML implementation for the data elements of this message is: 

<WCRequest> 
1 5 <WAuthorizedAndIssued> 

<WarrantyId Id-"9876540123XXXX" /> 
<WAmount Currency="USD">100000<AVAmount> 
<WClaimPeriod Days="14"/> 
<RCNameAndId> 
20 <X509IssuerSeriaI> 

<X509IssuerName>CN=LlBl Certificate Authority, OU=Root Entity, 0=Root Entity, 
C=US</X509IssuerName> 

<X509SerialNumber>979827336</X509SerialNumber> 
</X509IssuerSerial> 
25 </RCNameAndId> 
<SCNameAndId > 
<X509IssuerSerial> 

<X509IssuerName>CN=LlB2 Certificate Authority, OU=Root Entity, 0=Root Entity, 
C=US</X509IssuerName> 
30 <X509SerialNumber>918827438</X509SerialNumber> 

</X509IssuerSerial> 

</SCNameAndId > 

<SCTransactionId Id="12345631232131678387589" /> 
<RCTransactionId Id="65432855775334990885891" /> 
35 <WRTimestamp DateTime="20000812163000Z"/> 



5 



10 
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<IPNameAndId> 
<X509IssuerSerial> 

<X509IssuerName>CN=ROOT Certificate Authority, OU=Root Entity, 0=Root Entity, 
C=US</X509IssuerName> 
5 <X509SerialNumber>9 1 6627 1 88<;/X509SerialNumber> 
</X5 09IssuerSerial> 
</IPNameAndId> 

<WAltemateAmount Currency="GBP">140000<yWAltemateAmount> 
<ExpiryDate DateTime="20002212090000Z"/> 
1 0 <yw AuthorizedAndIssued> 

<WClaimAmount Currency="USD">100000<yWClaimAmount> 
<WRTimestampDateTime="20000820163000Z"/> 
<yWCRequest> 

15 A warranty claim notification message preferably includes the following data 

elements: 

• Warranty Claim Notification Message Code (indicating that the message is a 
warranty claim notification) 

• Warranty ID 

20 • Warranty Claim Number ID 

Claim Amount 
Claim Currency Type 

• Timestamp 

25 A preferred XML implementation for the data elements of this message is: 

<WCNotification> 

<WarrantyId Id="9876540123XXXX" /> 
<WClaimNo Id=" 123456" /> 
30 <WClaimAmount Currency="USD">100000<AVClaimAmount> 
<WRTimestamp DateTime="20000820163001Z"/> 
<AVCNotification> 

A warranty claim response message preferably includes the following data elements: 

35 



-39- 



NY2- 127251 1.1 



Warranty Claim Response Message Code (indicating that the message is a 
warranty claim response) 
Warranty ID 

Warranty Claim Number ED 
Claim Amount 
Claim Currency Type 
Timestamp 

A preferred XML implementation for the data elements of this message is: 

10 

<WCResponse> 

<WarrantyId Id="9876540123XXXX" /> 
<WClaimNo Id=" 1 23456" /> 

<WClaimAmount Currency="USD"> 1 00000<AVCIaimAmount> 
15 <WRTimestamp DateTime="20000820163001Z"/> 
</WCResponse> 

A warranty claim acknowledgment message preferably includes the following data 
elements: 

20 • Warranty Claim Acknowledgment Message Code (indicating that the 

message is a warranty claim acknowledgment) 

• Warranty ID 

• Warranty Claim Nimiber ID 

• Claim Amount 

25 • Claim Currency Type 

• Timestamp 

A preferred XML implementation for the data elements of this message is: 

30 <WCAck> 

<WarrantyId Id="9876540123XXXX" /> 

<WClaimNo Id=" 123456" /> 
• <WClaimAmount Currency="USD">100000</WClaimAmount> 

<WRTimestampDateTime="20000820163001Z"/> 
35 </WCAck> 



5 
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FIG. 15 shows a preferred list of data elements, and corresponding descriptions and 
restrictions, used to construct validation reporting messages that may be used to report the 
number of validations, performed by a participant in a preferred embodiment of the present 
system. 

5 An issuing participant validation reporting message preferably includes the 

following data elements: 

• An Issuing Participant Validation Reporting Message Code (indicating that 
the message is an issuing participant validation reporting message) 

• Validation Count 
10 • Validation Period 

Timestamp 

A preferred XML implementation for the data elements of this message: 

15 <WIPValidationReporting > 

<IPValidation Count="125"/> 

<PeriodFrom DateTime="200009 1 2 1 63050Z"/> 

<PeriodTo DateTime="2000 10121 63050Z"/> 

<WRTimestampDateTime="20001012163050Z7> 
20 </WIPValidationReporting > 

A root validation reporting message preferably includes the following data elements: 
A Root Entity Validation Reporting Message Code (indicating that the 
message is a root entity validation reporting message) 
25 • Issuing Participant Name and Identifier 

• Validation Count 

• Validation Period 

• Timestamp 

30 A preferred XML implementation for the data elements of this message is: 

<WIRValidationReporting> 

<IPNameAndId Id="987654" Name="IPl"/> 
<IP Validation Count="125"/> 
35 <PeriodFrom DateTime="20000912163050Z"/> 
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<PeriodTo DateTime="2000 1 0 1 2 1 6305 0Z"/> 
< WRTimestamp DateTime="2000 10121 63050Z"/> 
<AVIRValidationReporting> 

5 If an error occurs during the warranty process, then a warranty error message is 

generated. A warranty error message preferably includes the following data elements: 

• An Error Message Code (indicating that the message reports an error in the 
warranty process) 

• Error Code and Description 

10 • Subscribing Customer Transaction ID 

Relying Customer Transaction ID 

• Timestamp 

A preferred XML implementation for the data elements of this message is: 

<WError Code="901" Description=" Warranty Amount must be greater than 500 USD"> 
<SCTransactionId Id="12345631232131678387589" /> 
<RCTransactionId Id="65432855775334990885891" /> 
<WRTimestamp DateTime="200008 1 2 1 63050Z'V> 
</Werror> 

If the transaction between subscribing customer 106 and relying customer 108 does 
not take place, then a warranty canceled message is generated by the entity that requested 
the warranty and transmitted to the warranty issuer. Upon receipt of the warranty canceled 
message, the warranty amount is preferably released from both the requestor's and the 
issuer's warranty cap utilization. A warranty canceled message preferably includes the 
following data elements: 

A Warranty Canceled Message Code (indicating that the entity that requested 
the warranty wishes to cancel the warranty) 

• Date and Time Canceled 

• Warranty ID 

A preferred XML implementation for the data elements of this message is: 
35 <Wcanceled> 



15 



20 



25 



30 
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<DateTime Canceled="2000 2 1 20900002"/> 
<WarrantyId Id=987640123XXXX"> 
<yWcanceled> 

5 A preferred embodiment of a DTD for warranty messages is as follows: 

<?xml version="1.0" encoding="UTF-8"?> 
<!-- Root Entity Warranty Manager Version 1 .0 — > 
<!— Warranty Manager DTD ~> 
10 <!- 

Warranty=WRequest|WProposed|WConfirmation|WAuthorizedAndIssued|WReject|WIRVa 
lidationReporting|WIPValidationReporting|WError ~> 

<!ENTITY % XMLDSIG.dtd PUBLIC "-/AV3C//XMLDSIG//EN" "http://www.root 
15 entity.com/rC/2.0/XMLDSIG.dtd"> 
%XMLDSIG.dtd; 



<!ELEMENT WRequest 
20 (WAmount,WClaimPeriod,RCNameAndId,SCNameAndId,SCTransactionId,RCTransactio 
nId,WRTimestamp)> 
<!ELEMENT WAmount (#PCDATA)> 
<!ATTLIST WAmount 

Currency CDATA #REQUmED 

25 > 

<!ELEMENT WClaimPeriod EMPTY> 
<!ATTLIST WClaimPeriod 

Days CDATA #REQU1RED 

> 

30 <!ELEMENT RCTransactionId EMPTY> 
<! ATTLIST RCTransactionId 

Id CDATA #REQUIRED 

> 

<! ELEMENT SCTransactionId EMPTY> 
35 <!ATTLIST SCTransactionId 



-43 - 



NY2- I272SI1.1 



Id CDATA #REQUIRED 

> 

<!ELEMENT RCNameAndId (X509IssuerSerial)> 
<!ELEMENT SCNameAndId (X509IssuerSerial)> 
5 <!ELEMENT BPNameAndld (X509IssuerSerial)> 

. <!ELEMENT WRTimestamp EMPTY> 
<!ATTLIST WRTimestamp 

DateTime CDATA #RBQUIRED 

10 > 

<!ELEMENT WProposed 

(W Amount, WCIaimPeriod,SCTransactionId,RCTransactionId,WRTimestamp,IPNameAndI 
d,WAltemateAmount?)> 

15 <!ELEMENT WAltemateAmount (#PCDATA)> 
<!ATTLIST WAltemateAmount 

Currency CDATA #REQUIRED 

> 

<!ELEMENT WConfirmation 
20 (WarrantyId,WAjnount,WClaimPeriod,SCTransactionId,RCTransactionId, WRTimestamp,! 
PNameAndId,WAltemateAmount?,ExpiryDate)> 
<!ELEMENT Warrantyld EMPTY> 
<!ATTLIST Warrantyld 

Id CDATA #REQUIRED 

25 > 

<!ELEMENT ExpiiyDate EMPTY> 
<!ATTLIST ExpiryDate 

DateTime CDATA #REQUIRED 

> 

30 <!ELEMENT WAuthorizedAndlssued 

(Warrantyld, WAmount,WClaimPeriod,RCNameAndId,SCNameAiidId,SCTransactionId,R 
CTransactionId,WRTimestamp,IPNameAndId,WAltemateAmount?,ExpiryDate)> 

<!ELEMENT WReject (SCTransactionId,RCTi:ansactionId,WRTimestamp)> 
35 <!ATTLIST WReject 
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Code CD ATA #REQUIRED 
Reason CD ATA #REQUIRED 

> 

5 <! ELEMENT WIRValidationReporting (IPNameAndId, IP Validation, PeriodFrom, 
PeriodTo, WRTimestamp)> 

<! ELEMENT WIRAck (IPNanieAndId, IP Validation, PeriodFrom, PeriodTo, 
WRTimestanip)> 

10 

<!ELEMENT IPValidation EMPTY> 
<!ATTLIST IPValidation 

Count CDATA #R£QUIRED 

> 

15 

<!ELEMENT PeriodFrom EMPTY> 
<!ATTLIST PeriodFrom 

DateTime CDATA #REQUIRED 

> 

20 

<!ELEMENT PeriodTo EMPTY> 
<!ATTLIST PeriodTo 

DateTime CDATA #REQUIRED 

> 

25 

<!ELEMENT WlPValidationReporting (IPValidation, PeriodFrom, PeriodTo, 
WRTimestamp)> 

<!ELEMENT WError (SCTransactionId?,RCTransactionId?,WRTimestamp)> 
30 <!ATTLIST WError 

Code CDATA #REQUIRED 
Description CDATA #REQUIRED 

> 

<! ELEMENT WCRequest (WAuthorizedAndlssued, WClaimAmount, WRTimestamp)> 
35 <!ELEMENT WClaimNo EMPTY> 
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<!ATTLIST WClaimNo 
Id CD ATA #REQUIRED 

> 

<! ELEMENT WClaimAmount (#PCDATA)> 
5 <!ATTLIST WClaimAmount 

Currency CD ATA #REQUIRED 

> 

<!ELEMENT WCNotification (Warrantyld, WClaimNo, WClaimAmount, 
WRTimestamp)> 

10 <!ELEMENT WCAck (Warrantyld, WClaimNo, WClaimAmount, WRTimestamp)> 

<!ELEMENT WCResponse (Warrantyld, WClaimNo, WClaimAmount, WRTimestamp)> 

An alternative embodiment for implementing the the above-described messages and 
DTD is described in U.S. provisional application serial No. 60/ 259,796, filed January 4, 
15 2001, entitled Warranty Manager Application Programming Interface, Warranty Messaging 
Specification, and Warranty Manager Functional Requirements, which is hereby 
incorporated by reference. 

While the invention has been described in conjunction with specific embodiments, it 
is evident that numerous alternatives, modifications, and variations will be apparent to those 
20 skilled in the art in light of the foregoing description. 
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